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A Proposed File Access Protocol Specification 


Attached is a proposal for the File Access Protocol. FAP is an 
extension to FTP. I believe the specification is fairly general and 
should provide a good jumping-off place. I hope the protocol is 
specified in such a way as to fit with idiosyncrasies of most 


systems. If the protocol would cause an inordinate amount of burden 
on your system for one reason or another I would like to hear about 
Pes 


At some later date when the difficulties of implementation are better 
known, I would like to see several levels of implementation specified 
and implementation be done in terms of those levels. 


From rumors I have heard I believe this will also allow creation and 
transfer of what TENEX calls "holey" files. But, I am not sure of 
all of the implications of that, or what would happen (or should 
happen) when a "holey" file is moved to a site that doesn’t really 
have such a thing, per se. Comments from the TENEX crowd would be 
appreciated. 


I think some further work could be done to make FAP easier for record 
oriented systems. This would probably require an extra command or 
parameter to specify all operations are in terms of records. 

Comments are invited. 


In the long run though, I would like to see FAP thrown away. The 
commands as they are described merely add a finer structure to the 
present RETR, STOR, and APPE without much additional overhead. The 
sequence: 


OPEN R FOO.BAR CRLF 
READ ALL CRLF 
CLOS CRLF 


is equivalent to RETR FOO.BAR CRLF. FAP could be merged with FTP to 
give a much richer, coherent whole. 


In writing this document, I ran into the deficiency of reply codes 


for protocols. Three digits is no where near enough. I would like 
to suggest that as another interim solution we go to a five digit 
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reply with two for specific categories (such as Primary access, FTP 
results, etc.) and two for specific results. In the meantime, the 
NWG should begin considering a general scheme for reply codes -- one 
that doesn’t need revising every two years. 


Comments, complaints, etc. are welcomed. I may be reached through 
network mail at ISI (DAY) or Multics (DAY Cnet) or by phone at the 
University of Illinois (217) 333-6544. 


A 
Proposed 
File Access Protocol 
Specification 


John Day 
6/7/73 
I. INTRODUCTION 


The purpose of the File Access Protocol is to provide a method for 
processes to access non-local files in either a sequential or non- 
sequential manner. Unlike the proposed Mail Protocol, FAP is an 
extension of FTP and not a subsystem. In general FAP is compatible 
with the rest of FTP. Those modifications which are necessary are 
specified below. 


The intent of this protocol is to allow processes to specify to the 
remote file system where in the file they wish the next operation to 
start and how much data to move. Thus only the part of a file 
necessary for a process’ computation need be transferred, rather than 
the entire file. Thus transmission times and storage requirements 
may be held down. In short, the rationale for a File Access Protocol 
on the network is the same as the rationale for "random-accessed" 
files in a standard operating system. 


The file Access Protocol uses the connection model, data 
representations, and transmission methods of the File transfer 
Protocol. All data transmissions in FAP are handled according to the 
description in FTP Section III.C with the following modifications. 
In Stream mode, the minimum byte size is increased to 4 bits. 
Another control code (value 4) is used to indicate "end of 
transmission". An combination of EOT, EOR, or EOF may be indicated 
by the proper control code. With this method it is not necessary to 
close the connection after each access; a practice not highly 
recommended. In Block mode, bit 5 of the descriptor field of the 
header is set noting that this block is the end of transmission. In 
addition to this, FAP uses a File Pointer (FP). The file pointer 


Day [Page 2] 


RFC 520 A Proposed File Access Protocol Specification 25 June 1973 


EE: 


Day 


points into the file and is the point at which the next FAP read or 
write will commence. The file pointer is a general mechanism for 
addressing a file and should be flexible enough to handle both stream 
and record oriented systems. 


PROBLEMS OF IMPLEMENTATION 


As usual, not all systems will be able to implement this protocol in 
its full generality. The approach that should be taken is that no 
host should be required to provide for network users (in the name of 
complete protocol implementation) service it does not provide its 
local users. 


Some systems allow "random" access to some kinds of files on its 
system and not to others. In this case, this should be their 
implementation, i.e., not all operations are valid for all kinds of 
files. 


Some systems cannot move the byte pointer backwards without opening 
and closing the file. They should not be required to do this 
(although they may if they wish), but they should allow "spacing" 
down a file some distance before starting a transfer. 


Some systems may not allow read and write access to be available 
without closing and reopening the file. Systems should not be 
required to do both. 


In general, the rules of implementation are: 


1) If a system normally allows that particular kind of access to 
that particular file then it should be allowed; if not, the system 
should not be forced to implement it. (In many cases, the legality 
cannot be known until the operation is attempted; i.e., it cannot 
be told of the first two cases above if they are legal when the 
file is opened but only on the read or write which violates the 
implementation restrictions). 


2) A system should not try to simulate a facility if the 
simulation has side effects. For example, if simulating the 
capability of moving the byte pointer to the desired position has 
some side effects, then the simulation should be left to the 
process accessing the file. 


3) All implementors should make known the capabilities of their 
implementations via NIC documents. 
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III. FILE ACCESS PROTOCOL 


The FAP extension to FTP includes 6 new commands and the file 
pointer. Any implementation requires the file pointer and all six 
commands. But, as described above, it is not necessary to implement 
the commands in their full generality. 


III.1 THE FILE POINTER 


The file pointer represents an index or address within the file. The 
units by which the index is measured, is "logical byte size" and does 
not include any bytes related to transmission or structure. In 


particular, for transmission mode Stream and structure Record, the 
EOR and EOF markers are not counted. Local transformations on data 
must be taken into account. For example, Multics stores CRLF as NL. 
In this case, NL counts as two ASCII bytes since it was transmitted 
to or will be sent from Multics as CRLF. If transmission Mode is 
Image then the logical byte size is taken as the transmission byte 
size. There are two commands which operate on the file pointer: 1) 
SETP to move the pointer and 2) GETP to find out where it is at. 
These are described below in more detail. 


The file pointer may take on three classes of values. All may be 
mapped to some decimal number. The value B represents the beginning 
of the file (Byte 0). The value E represents the end of the file (or 
Byte n for a file n bytes long). The byte pointer may also take on 
any value between 0 and n. 


A file of n bytes 


If a file is stored under set of parameters (TYPE, etc.) and 
operations are attempted on it under different parameters, the server 
does not guarantee that the information will be valid. 

III.2 COMMANDS 

III.2.1 OPEN <direction> <pathname> 
This command instructs the server to "open" the file <pathname> for 


access in the direction specified. The directions are read, R write, 
W; or both, B. A read direction implies that the data connection is 
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from server to user; write, from user to server; and both implies 
connections each ways. Functionally, this command corresponds to 
RETR or STOR. Therefore, all the FTP parameter commands (TYPE, MODE, 
etc.) must be sent before the file is opened. If the direction is 
write (W) and the file specified by the pathname does not exist, 
there is an implied create with the open. The success of this 
create, is, of course, dependent on local access privileges and 
possibly whether or not an ALL command was sent. If applicable, the 
file created should be of the most general kind of file on which 
"random" access is allowed. (This is to allow the largest degree of 
compatibility with operations that may follow). This should be 
ignored if some site specific command has already specified the kind 
of file. This command identifies the file on which subsequent 
operations are to be performed. After the file is opened, the file 
pointer is at B and any of the other five FAP commands may be sent. 
It is acknowledged that some systems cannot open a file for access in 
both directions; an error reply 402 should be sent for this response. 


Replies 

258 451 500 504 550 
402 454 501 505 

434 455 502 506 

4550 457 503 507 


TII.2.2 SETP <argument> 


This command causes the file pointer to be set to the number 


specified in the argument. This value will be the ordinal number of 
the starting position of the next operation. (Byte 0 is the first 
byte in the file). The argument may take on two other values besides 


<decimal number> : B, for BEGIN, which sets the file pointer at the 
beginning of a file (i.e. 0) and E, for END, which sets the file 
pointer to the last byte in the file. Two error conditions are 
possible. If the argument specifies an illegal change of file 
pointer (such as moving it backwards on some systems), then the error 
reply 402 should be sent. If the argument attempts to move the file 
pointer off the end of the file, then the EOF: <byte number> reply 
should be sent with the address of the end of the file (E), and the 
file pointer left at E. 
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III.2.3 GETP 


This command requests the server to return the value of the file 
pointer as a decimal number. 


III.2.4 READ <arg> 


This command instructs the server to move as many bytes as specified 
(of size logical byte size) from the server to the user. The values 
the argument may take on are <decimal number> and ALL. ALL is 
interpreted as all data from the present position of the file pointer 
to the end-of-file. If a read requests more bytes than in the file, 
the number of bytes from the present position to the end of file 
should be transferred and an EOF: <byte number> response returned 
noting the position of the end of file. If the file is Record 
structured and a READ requests more bytes than in the record, then 
the number of bytes in the record from the file pointer are moved and 
the EOR: <byte number> reply is sent noting the end of record. The 
action of a READ leaves the file pointer at the position before the 
read plus the number of bytes moved, (i.e., updated). The EOF 
condition leaves it at 


ti 
. 


Replies 

258 480 

402 481 

450 482 

452 500-507 
455 


III.2.5 WRITe <arg> 


This command instructs the server to accept as many bytes as 
specified from the user. The result updates the value of the file 
pointer. The values the argument may take on are <decimal number> or 
ALL. ALL is interpreted as all data from the present position of the 
byte pointer to the end-of-file (or beyond). Associated with the 
write is an implied "append", if necessary previous information has 
been sent (such as allocation) and if the file’s access privilege 
allow the append. If a write specifies more bytes than there are 
between the file pointer and the end-of-file, and expansion is not 
allowed, no data is sent and the file pointer is not moved. An error 
is returned specifying the byte position of the EOF. If the file is 
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Record structured and a WRIT attempts to move more bytes than there 
are in the record, the file pointer is not moved and the EOR: <byte 
number> reply is sent noting the end of record. 


Replies 

258 480 

402 481 

450 482 

452 500-507 
453 

-2.6 CLOS 


This command instructs the server to "close" the presently open file, 
if any. The receipt of a CLOS without an open file is not an error. 
The effect is to notify the server that further operations are not 
directed at the file which is presently open. If an open is received 
by the server and it has a file open, it should close the open file 
and open the new one. 


SUMMARY 
1 SYNTAX 
OPEN <direction> <pathname> CRLF 
CLOS CRLF 
SETP <byte pointer arg> CRLF 
GETP CRLF 
READ <transfer argument> CRLF 
WRIT <transfer argument> CRLF 
<direction>::= R|W|B 
<byte pointer argument>::= B|E|<decimal number> 


<transfer argument>::=ALL|<decimal number> 


<byte number>::= <decimal number> 
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IV.2 REPLIES USED BY FAP 


Day 


258 
402 
433 


450 
451 
452 
453 
454 
455 
457 
480 
481 
482 
483 
500 
501 
502 
504 
505 
506 
507 
550 


Operation successful 

Command not implemented for requested value or action 
Cannot transfer files w/o valid account. Enter account & 
resend command. 

FTP: file not found 

FTP: file access denied 

FTP: file transfer incomplete, data connection closed. 
FTP: file transfer incomplete, insufficient storage space. 
FTP: cannot connect to your data socket 

FTP: file system error not covered by other reply codes. 
FTP: transfer parameters in error. 

EOR: <byte number> 

EOF: <byte number> 

File not open for operation 

FP: <byte pointer> 

Last command line completely unrecognized. 

Syntax of last command is incorrect. 

Last command invalid (ignored), illegal parameter combination. 
Last command invalid, action not possible at this time. 
Last command conflicts illegally with previous command(s). 
Last command not implemented by the server. 

Catchall error reply. 

Bad pathname specification (e.g., syntax error). 


[ This RFC was put into machine readable form for entry ] 
[ into the online RFC archives by Via Genie ] 
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